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CHAPTER 14 DISTRIBUTED TRANSACTIONS 



14.4 concurrency control in distributed transactions «f 
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item accessed by transaction U cornrnits after the version accessed by T at one server, 
then if T and U access the same data item as one another at other servers, they must 
commit them in the same order. To achieve the same ordering at all the servers, the 
servers must agree as to the ordering of their timestamps. A timestamp consists of a pair 
<local timestamp, ser\*er~id>. The agreed ordering of pairs of timestamps is based on a 
comparison in which the server-id pan is iess significant. 

The same ordering of transactions can be achieved at all the servers even if their 
local clocks are not synchronized. However for reasons of efficiency it is required that 
the timestamps issued by one server should be roughly synchronized with those issued 
by the other servers. When this is the case, the ordering of transactions generally 
corresponds to the order in which they are started in real time. Timestamps can be kept 
roughly synchronized by the use of synchronized local physical clocks (see Chapter 10). 

When timestamp ordering is used for concurrency control, conflicts are resolved 
as each operation is performed. If the resolution of a conflict requires a transaction to be 
aborted, the coordinator will be informed and it will abort the transaction at all the 
workers. Therefore any transaction that reaches the client request to commit should 
always be able to commit. Therefore a server involved as a worker in the two- phase 
cornmil protocol will normally agree to commit. The only situation in which a worker 
will not agree to commit is if it had crashed during the transaction. 

Optimistic concurrency control in distributed transactions 

Recall thai with optimistic concurrency control, each transaction is validated before it is 
allowed to commit. Servers assign transaction numbers at the start of validation and 
transactions are serialized according to the order of the transaction numbers. A 
distributed transaction is validated by a collection of independent servers each of which 
validates transactions thai access its own data items. The validation at all of the servers 
takes place during the first phase of the two-phase commit protocol. 

Consider the following interleavings of transactions T and U that access data 
items A and B at servers X and Y respectively. 



T 




U 




Read(A) 


at X 


Read(B) 


at Y 


Write* A) 




Wrire(B) 




Read(B) 


at Y 


Read(A) 


atX 


Write(B) 




Write(A) 





The transactions access the data items in the order T before U at server X and in the order 
U before T at server Y. Now suppose that T and U start validation at about the same 
time, but server X validates T first and server Y validates U first. Recall that Chapter 1 3 
recommends a simplification of the validation protocol that makes a rule that only one 
transaction may perform validation and write phases at the same time. Therefore each 
server will be unable to validate the other transaction until the first one has completed. 
This is an example of corrtmitment deadlock. 
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The validation rules in Chapter 13 assume.that validation is fast which is! 
single server transactions. However in a distributed transaction, the two-pha 
protocol may take some time and will delay other transactions from entering y- 
until a decision on the current transaction has been obtained. A parallel v- 
protocol is generally used to increase the concurrency at each individual senr; 
and Robinson [1981] describe parallel validation in their original paper. It mif 
conflicts between write operations of the transaction being validated against f 
operations of other concurrent transactions. 

If parallel validation is used, transactions will not suffer from con 
deadlock. However if servers simply perform independent validations, it is possi. 
different servers of a distributed transaction may serialize the same set of tra 
different orders. For example with T before U at server X and U before T at j 
our example. 

The servers of distributed transactions must prevent this from happenin 
approach is that after a local validation by each server, a global validation is ca 
[Ceri and Owicki 1982]. The global validation checks that the combinauV 
orderings at the individual servers is serializable. That is, that the transacricT 
validated is not involved in a cycle. 

Another approach is that all of the servers of a particular transaction use \ 
globally unique transaction number at the start of the validation [Schlageter 19^ 
coordinator of the two-phase commit protocol is responsible for generating the 
unique transaction number and passes it to the workers in the CanCommit? l 
As different servers may coordinate different transactions, the servers must (" 
distributed timestamp ordering protocol) have an agreed order for the 
numbers they generate. 



14.5 Distributed deadlocks 



The subsection on deadlocks in Section 13.2 shows that deadlocks can arise^ 
single server when locking is used for concurrency control. Servers must eithefe 
or detect and resolve deadlocks. Using timeouts to resolve possible deadl ^ 
clumsy approach - it is difficult to choose an appropriate timeout intc- 
transactions are aborted unnecessarily. With deadlock detection schemes, a tr? 
is aborted only when it is involved in a deadlock. Most deadlock detection 
operate by finding cycles in the transaction wait-for graph. In a distributed 
involving multiple servers being accessed by multiple transactions, a globalg 
graph can in theory be constructed from the local ones. There can be a cycle in 
wait-for graph that is not in any single local one - that is, there can be a ais 
deadlock. Recall that the wait-for graph is a directed graph in which nodes i 
transactions and data items; and edges represent either a data item held by a « 
or a transaction waiting for a data item. There is a deadlock if and only if & ere | 
in the wait-for graph. . £ 

Figure 14.13 shows the interleavings of the transactions U, V and w mv ^ 
data items A and B managed by servers X and Y and data items C and D ^ - 
server Z. 
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